[ROCm][Quantization] Implement Fp8Config shared-expert FSE compatibility check - #53068

Purpose

is_shared_expert_quant_fse_compatible() gates AITER fused shared experts (FSE) behind a
quantization compatibility check that currently implements only QuarkConfig and
DeepseekV4FP8Config. Every other quantization falls through to a catch-all rejection:

shared-expert FSE quantization compatibility is not implemented for Fp8Config

The practical effect is that models loading with the plain Fp8Config accept
VLLM_ROCM_USE_AITER_FUSION_SHARED_EXPERTS=1 and then silently run unfused. There is no error
and no non-zero exit, only one warning per MoE layer per rank buried in startup logs. On
GLM-5.2-FP8 (78 MoE layers, TP8) that is 600+ near-identical warning lines, and it is easy to
believe the flag took effect when it did not.

This PR implements the TODO that sits directly above the catch-all return:

# TODO: Extend FSE support detection to other quantization methods. Typically,
# one would check that the experts and shared_experts use the same
# quantization config.

Fp8Config carries a single global weight_block_size and activation_scheme with no
per-layer overrides, so the only source of per-layer variation is ignored_layers. Routed and
shared experts therefore share a quantization config exactly when they are either both
quantized or both ignored. Skip status is resolved with is_layer_skipped() using the config's
own packed_modules_mapping and ignored_layers_match_mode — the same call
Fp8Config.get_quant_method() makes — so the check asks the quantization layer the question it
already asks itself rather than inventing a parallel rule.

The branch fails closed: any asymmetry between the routed and shared experts returns False
with a reason mirroring the existing Quark message. It is also restricted to fp8-serialized
checkpoints, since the online-quantization path has not been exercised. It is placed below the
DeepseekV4FP8Config branch, which subclasses Fp8Config and needs its own MXFP4 handling.

Other quantizations (compressed-tensors, GPTQ, AWQ, ModelOpt) still fall through the catch-all
and are unaffected.

Test Plan

Unit:

pytest tests/model_executor/layers/test_fused_shared_expert.py -k fp8

Seven new cases extend the existing gate tests: uniformly quantized experts, non-expert
exclusions (layernorms, mlp.gate, lm_head) which must not disable FSE, both expert groups
ignored, three asymmetric-exclusion negative controls (shared excluded, routed excluded, one of
two projections excluded), and a non-serialized checkpoint.

End to end, zai-org/GLM-5.2-FP8, 8x MI325X (gfx942), TP8, vllm bench serve with random
131,072 input / 1,024 output, 20 prompts, seed 4, 2 warmups:

VLLM_ROCM_USE_AITER=1 VLLM_ROCM_USE_AITER_MOE=1 \
VLLM_ROCM_USE_AITER_FUSION_SHARED_EXPERTS=1 \
vllm serve zai-org/GLM-5.2-FP8 -tp 8 --block-size 64 --gpu-memory-utilization 0.83

Test Result

Unit tests: 7 new cases pass with the change and all 7 fail without it. The 14 pre-existing
non-GPU cases in the same module continue to pass.

End to end the flag now takes effect: the per-layer cannot be enabled warning is gone, KV
cache size is unchanged at 2,240,512 tokens, AITER block-scale FP8 MoE kernels are selected
(fmoe_bf16_blockscaleFp8_g1u1_vs_silu_*), and output is correct on arithmetic, factual recall
and text completion prompts.

Output token throughput, FSE off vs on:

Latency, FSE off → on:

TTFT improves at every concurrency because prefill always presents the fused grouped GEMM with
a large token batch. TPOT improves at concurrency 4 and above but regresses 7.5% at concurrency
2, where the decode batch is too small to amortize the fused kernel and a dedicated dense GEMM
for the single shared expert wins; there the prefill gain and decode loss roughly cancel. The
crossover lies between concurrency 2 and 4. Concurrency 2 was measured twice on separate days
with a server restart between, agreeing to within 0.05%, so these deltas are signal rather than
noise.